Codecov Report

❌ Patch coverage is 91.58879% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.85%. Comparing base (ca2a5f5) to head (4e8c88f).

@@             Coverage Diff             @@
##              main      #38      +/-   ##
===========================================
- Coverage   100.00%   94.85%   -5.15%     
===========================================
  Files            7       10       +3     
  Lines           68      175     +107     
  Branches         0       20      +20     
===========================================
+ Hits            68      166      +98     
- Misses           0        5       +5     
- Partials         0        4       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thinking about it more, the other thing I don't love is that we're going to have to alter ResultGen every time we want to support returning a new type. I think that will be more annoying than building tools that help us write the appropriate wrappers in an automated way, but see what you think and let's see.

Yes, I agree with both points you made. I was also concerned about ResultGen turning into a huge container with hundreds of objects whose types we constantly need to check. Ultimately, it depends on how many object types we’ll have to handle in the end. Still you made a very good point, the design is not very flexible, since we would need to modify basically every layer whenever we want to support a new type. Right now, the more I think about the whole ResultGen idea, the less convinced I become.

What I initially liked about it was that having a single, centralized array unified memory management. It also led me to create the tag attribute, which helped flag whether a slot is free or not. And freeing the error_v array allowed me to use it for bubbling up errors instead.

But perhaps these are more "didactic" conveniences than actual code advantages.. we could achieve the same behavior in other ways I think.